End of life: 12/31/2027, End of support: 4/30/2027, Latest version: 6.1.1

Announce: https://www.djangoproject.com/weblog/2026/aug/04/security-releases/

CVE JSON Record for CVE-2026-15307: https://www.cve.org/CVERecord?id=CVE-2026-15307

CVE JSON Record for CVE-2026-15337: https://www.cve.org/CVERecord?id=CVE-2026-15337

CVE JSON Record for CVE-2026-15830: https://www.cve.org/CVERecord?id=CVE-2026-15830

CVE JSON Record for CVE-2026-15920: https://www.cve.org/CVERecord?id=CVE-2026-15920

In accordance with our security release policy, the Django team is issuing releases for Django 6.0.8 and Django 5.2.17. These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as possible.

CVE-2026-15307: Server-side file-write and request forgery via spatial lookups

Spatial lookups allowed str and dict lookup values to be passed to GDALRaster when they represented rasters. Depending on the raster driver, this could write a file to disk (in some cases enabling remote code execution) or issue a network request as the Django process user. Because the admin changelist permits filtering via ModelAdmin.lookupallowed(), the flaw was reachable by staff users with view permissions on any registered model containing a spatial field.

The following types are now disallowed by spatial lookups:

- dict - A str that is not a valid GEOSGeometry, e.g. a serialized dictionary

This is a backward incompatible change. As a reminder, all untrusted user input should be validated before use. For that reason, assignments to model fields are unaffected and still accept these input types.

For guidance on how to keep using these types in spatial lookups, on validating untrusted input, and on further security considerations, see the raster security considerations documentation.

This issue has severity "high" according to the Django security policy.

Thanks to Bence Nagy, localhost-detect, and kimchunbok for the report.

CVE-2026-15337: Potential denial-of-service vulnerability in checkforlanguage()

django.utils.translation.checkforlanguage() was subject to a potential denial-of-service attack when checking many distinct, very long language codes. Each code was used as a key in an in-memory cache, consuming process memory.

The language value reaches this function through the django.views.i18n.setlanguage() view (not active by default) from POST data. Since request data is limited by DATAUPLOADMAXMEMORYSIZE and the cache is configured to store a maximum number of entries, the memory that could be consumed was bounded.

To mitigate this vulnerability, language codes longer than 500 characters are now rejected before the cached lookup.

This issue has severity "low" according to the Django security policy.

Thanks to Jaeyoung Jang for the report.

CVE-2026-15830: Potential denial-of-service vulnerability via nested geometry collections

GEOSGeometry was subject to a potential denial-of-service attack when provided deeply nested GEOMETRYCOLLECTION objects, leading to a segmentation fault in GEOS. A maximum depth of 198 GEOMETRYCOLLECTIONs is now enforced for the well-known text (WKT) format, and a maximum number of 198 GEOMETRYCOLLECTIONs in total (breadth and depth) is enforced for well-known binary (WKB).

Lookups against spatial fields and the GeometryField form field were also affected.

The limit can be customized through the new maxgeomcollections argument, available on GEOSGeometry, the form field, and the model field. The limit is not applied to GeoJSON inputs, as they were parsed by GDAL and are not affected.

This issue has severity "moderate" according to the Django security policy.

Thanks to Andrew MacPherson and kimchunbok for the report.

CVE-2026-15920: Potential cross-site scripting via URLField values in the admin

The admin renders URLField values as clickable links on changelist views and read-only fields. The link was generated without validating the value as a safe URL, so a stored value using a potentially dangerous scheme was rendered as a link.

URLField values shown via displayforfield are now validated using URLValidator before a link is rendered, and displayed as plain text if validation is failed.

This issue has severity "moderate" according to the Django security policy.

Thanks to Egor Saltykov for the report.

Affected supported versions

Django main Django 6.1 (currently at release candidate status) Django 6.0 Django 5.2

Resolution

Patches to resolve the issue have been applied to Django's main, 6.1 (currently at release candidate status), 6.0, and 5.2 branches. The patches may be obtained from the following changesets.

CVE-2026-15307: Server-side file-write and request forgery via spatial lookups

On the main branch On the 6.1 branch On the 6.0 branch On the 5.2 branch

CVE-2026-15337: Potential denial-of-service vulnerability in checkforlanguage()

On the main branch On the 6.1 branch On the 6.0 branch On the 5.2 branch

CVE-2026-15830: Potential denial-of-service vulnerability via nested geometry collections

On the main branch On the 6.1 branch On the 6.0 branch On the 5.2 branch

CVE-2026-15920: Potential cross-site scripting via URLField values in the admin

On the main branch On the 6.1 branch On the 6.0 branch On the 5.2 branch

The following releases have been issued

Django 6.0.8 (tarball | checksums) Django 5.2.17 (tarball | checksums)

The PGP key ID used for this release is Natalia Bidart: 2EE82A8D9470983E

General notes regarding security reporting

As always, we ask that potential security issues be reported via private email to security () djangoproject com, and not via Django's Trac instance, nor via the Django Forum. Please see our security policies for further information.

An issue was discovered in Django 5.2 before 5.2.15 and 6.0 before 6.0.6. django.middleware.cache.UpdateCacheMiddleware in Django does not add Authorization to the Vary response header for requests bearing that header without Cache-Control: public, which allows remote attackers to read private cached responses via unauthenticated requests to the same URL. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Shai Berger for reporting this issue.

An issue was discovered in Django 6.0 before 6.0.6 and 5.2 before 5.2.15. django.core.mail.backends.smtp.EmailBackend in Django fails to prevent reuse of a partially-initialized connection after a failed STARTTLS handshake when failsilently=True, which allows on-path network attackers to read email content via cleartext interception. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Kasper Dupont for reporting this issue.

End of life: 4/30/2027, End of support: 8/4/2026, Latest version: 6.0.8

An issue was discovered in Django 4.2 before 4.2.24, 5.1 before 5.1.12, and 5.2 before 5.2.6. FilteredRelation is subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the kwargs passed QuerySet.annotate() or QuerySet.alias().

An issue was discovered in Django 4.2 before 4.2.24, 5.1 before 5.1.12, and 5.2 before 5.2.6. FilteredRelation is subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the kwargs passed QuerySet.annotate() or QuerySet.alias().

End of life: 4/30/2028, End of support: 12/3/2025, Latest version: 5.2.17

The wrap() and :tfilter:wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings.

Affected versions =================

Django main development branch Django 5.2 (currently at beta status) Django 5.1 Django 5.0 Django 4.2

https://www.djangoproject.com/weblog/2024/dec/04/security-releases/

In accordance with our security release policy <https://docs.djangoproject.com/en/dev/internals/security/>, the Django team is issuing releases for Django 5.1.4 <https://docs.djangoproject.com/en/dev/releases/5.1.4/>, Django 5.0.10 <https://docs.djangoproject.com/en/dev/releases/5.0.10/>, and Django 4.2.17 <https://docs.djangoproject.com/en/dev/releases/4.2.17/>. These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as possible.

CVE-2024-53907: Potential denial-of-service in django.utils.html.striptags() =================================================================================

The striptags() method and striptags template filter are subject to a potential denial-of-service attack via certain inputs containing large sequences of nested incomplete HTML entities.

Thanks to jiangniao for the report.

This issue has severity "moderate" according to the Django security policy.

CVE-2024-53908: Potential SQL injection in HasKey(lhs, rhs) on Oracle =========================================================================

Direct usage of the django.db.models.fields.json.HasKey lookup on Oracle is subject to SQL injection if untrusted data is used as a lhs value. Applications that use the jsonfield.haskey lookup through the syntax are unaffected.

Thanks to Seokchan Yoon for the report.

This issue has severity "high" according to the Django security policy.

Affected supported versions ===========================

Django main Django 5.1 Django 5.0 Django 4.2

Resolution ==========

Patches to resolve the issue have been applied to Django's main, 5.1, 5.0, and 4.2 branches. The patches may be obtained from the following changesets.

CVE-2024-53907: Potential denial-of-service in django.utils.html.striptags() -----------------------------------------------------------------------------

On the main branch < https://github.com/django/django/commit/49ff1042aa66bb25eda87e9a8ef82f3b0ad4eeba On the 5.1 branch < https://github.com/django/django/commit/bbc74a7f7eb7335e913bdb4787f22e83a9be947e On the 5.0 branch < https://github.com/django/django/commit/a5a89ea28cc550c1b29b03f9e14ef3c128ec1e84 On the 4.2 branch < https://github.com/django/django/commit/790eb058b0716c536a2f2e8d1c6d5079d776c22b CVE-2024-53908: Potential SQL injection in HasKey(lhs, rhs) on Oracle ---------------------------------------------------------------------

On the main branch < https://github.com/django/django/commit/8f8dc5a1fca7d076e749f307f6573af3512e7e99 On the 5.1 branch < https://github.com/django/django/commit/6943d61818e63e77b65d8b1ae65941e8f04bd87b On the 5.0 branch < https://github.com/django/django/commit/ff08bb6c70aa45f83a5ef3bd0b601c7c9d1a7642 On the 4.2 branch < https://github.com/django/django/commit/7376bcbf508883282ffcc0f0fac5cf0ed2d6cbc5 The following releases have been issued =======================================

Django 5.1.4 (download Django 5.1.4 <https://www.djangoproject.com/m/releases/5.1/Django-5.1.4.tar.gz> | 5.1.4 checksums <https://www.djangoproject.com/m/pgp/Django-5.1.4.checksum.txt>) Django 5.0.10 (download Django 5.0.10 <https://www.djangoproject.com/m/releases/5.0/Django-5.0.10.tar.gz> | 5.0.10 checksums <https://www.djangoproject.com/m/pgp/Django-5.0.10.checksum.txt>) Django 4.2.17 (download Django 4.2.17 <https://www.djangoproject.com/m/releases/4.2/Django-4.2.17.tar.gz> | 4.2.17 checksums <https://www.djangoproject.com/m/pgp/Django-4.2.17.checksum.txt>)

The PGP key ID used for this release is Sarah Boyce: 3955B19851EA96EF < https://github.com/sarahboyce.gpg>

General notes regarding security reporting ==========================================

As always, we ask that potential security issues be reported via private email to security () djangoproject com, and not via Django's Trac instance, nor via the Django Forum, nor via the django-developers list. Please see our security policies <https://www.djangoproject.com/security/> for further information.

End of life: 4/7/2026, End of support: 12/4/2023, Latest version: 4.2.30

End of life: 4/7/2026, End of support: 12/4/2023, Latest version: 4.2.30

Direct usage of the django.db.models.fields.json.HasKey lookup on Oracle is subject to SQL injection if untrusted data is used as a lhs value. Applications that use the lookup through the syntax are unaffected.

End of life: 12/3/2025, End of support: 4/2/2025, Latest version: 5.1.15

End of life: 12/3/2025, End of support: 4/2/2025, Latest version: 5.1.15

End of life: 4/2/2025, End of support: 8/7/2024, Latest version: 5.0.14

End of life: 4/2/2025, End of support: 8/7/2024, Latest version: 5.0.14

Description: urlize, urlizetrunc, and AdminURLFieldWidget were subject to a potential denial-of-service attack via certain inputs with a very large number of Unicode characters.

Affected versions =================

Django main development branch Django 5.1 (currently at release candidate status) Django 5.0 Django 4.2

getsupportedlanguagevariant() was subject to a potential denial-of-service attack when used with very long strings including a specific set of characters.

Affected versions =================

Django main development branch Django 5.1 Django 5.0 Django 4.2

https://www.djangoproject.com/weblog/2023/nov/01/security-releases/

In accordance with our security release policy is issuing Django 4.2.7 <https://docs.djangoproject.com/en/dev/releases/4.2.7/>, Django 3.2.23 <https://docs.djangoproject.com/en/dev/releases/3.2.23/>. These releases addresses the security issue detailed below. We encourage all users of Django to upgrade as soon as possible. =========================================================================================

The NFKC normalization is slow on Windows. As a consequence, of service attack via certain inputs with a very large number of Unicode characters.

In order to avoid the vulnerability, invalid values longer than validation anyway.

Thanks MProgrammer <https://hackerone.com/mprogrammer> for the report.

This issue has severity "moderate" according to the Django security policy.

Affected supported versions ===========================

Django main branch Django 5.0 (currently at beta status) Django 4.2 Django 4.1 Django 3.2

Resolution ========== following changesets: The following releases have been issued:

General notes regarding security reporting ==========================================

As always, we ask that potential security issues be reported via private email to security () djangoproject com, and not via Django's Trac instance or the django-developers list. Please see our security policies <https://www.djangoproject.com/security/> for further information.

End of life: 12/1/2023, End of support: 4/5/2023, Latest version: 4.1.13

End of life: 12/1/2023, End of support: 4/5/2023, Latest version: 4.1.13

End of life: 4/1/2023, End of support: 8/3/2022, Latest version: 4.0.10

End of life: 4/1/2023, End of support: 8/3/2022, Latest version: 4.0.10

End of life: 4/1/2024, End of support: 12/7/2021, Latest version: 3.2.25

End of life: 4/1/2024, End of support: 12/7/2021, Latest version: 3.2.25

End of life: 12/7/2021, End of support: 4/6/2021, Latest version: 3.1.14

End of life: 12/7/2021, End of support: 4/6/2021, Latest version: 3.1.14

End of life: 4/6/2021, End of support: 8/3/2020, Latest version: 3.0.14

End of life: 4/6/2021, End of support: 8/3/2020, Latest version: 3.0.14